-
Notifications
You must be signed in to change notification settings - Fork 547
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rbd: do not try to run resizefs
on an encrypted BlockMode volume
#3958
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
internal/rbd/nodeserver.go
Outdated
@@ -512,6 +512,11 @@ func resizeNodeStagePath(ctx context.Context, | |||
if err != nil { | |||
return status.Error(codes.Internal, err.Error()) | |||
} | |||
|
|||
// if this is a AccessType=Block volume, do not attempt filesystem resize |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just add more details that if the filesystem is created by te user it user's responsibility to resize the filesystem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should be clear if an application uses BlockMode volumes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i was looking for why we should not attempt for filesystem resize in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, does this extra comment help?
/test ci/centos/k8s-e2e-external-storage/1.25 |
/test ci/centos/k8s-e2e-external-storage/1.26 |
/test ci/centos/k8s-e2e-external-storage/1.27 |
/test ci/centos/mini-e2e-helm/k8s-1.25 |
/test ci/centos/mini-e2e-helm/k8s-1.26 |
/test ci/centos/mini-e2e-helm/k8s-1.27 |
/test ci/centos/mini-e2e/k8s-1.25 |
/test ci/centos/mini-e2e/k8s-1.26 |
/test ci/centos/mini-e2e/k8s-1.27 |
/test ci/centos/upgrade-tests-cephfs |
/test ci/centos/upgrade-tests-rbd |
Issues with the Ceph RPM repository caused downloading/installing updates and dependencies to fail. |
/test ci/centos/k8s-e2e-external-storage/1.25 |
/test ci/centos/k8s-e2e-external-storage/1.26 |
/test ci/centos/k8s-e2e-external-storage/1.27 |
/test ci/centos/mini-e2e-helm/k8s-1.25 |
/test ci/centos/mini-e2e-helm/k8s-1.26 |
/test ci/centos/mini-e2e-helm/k8s-1.27 |
/test ci/centos/mini-e2e/k8s-1.25 |
/test ci/centos/mini-e2e/k8s-1.26 |
/test ci/centos/mini-e2e/k8s-1.27 |
/test ci/centos/upgrade-tests-cephfs |
/test ci/centos/upgrade-tests-rbd |
@Mergifyio queue |
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at f60a358 |
When a volume has AccessType=Block and is encrypted with LUKS, a resize of the filesystem on the (decrypted) block-device is attempted. This should not be done, as the application that requested the Block volume is the only authoritive reader/writer of the data. In particular VirtualMachines that use RBD volumes as a disk, usually have a partition table on the disk, instead of only a single filesystem. The `resizefs` command will not be able to resize the filesystem on the block-device, as it is a partition table. When `resizefs` fails during NodeStageVolume, the volume is unstaged and an error is returned. Resizing an encrypted block-device requires `cryptsetup resize` so that the LUKS header on the RBD-image is updated with the correct size. But there is no need to call `resizefs` in this case. Fixes: ceph#3945 Signed-off-by: Niels de Vos <ndevos@ibm.com>
/test ci/centos/k8s-e2e-external-storage/1.25 |
/test ci/centos/k8s-e2e-external-storage/1.26 |
/test ci/centos/k8s-e2e-external-storage/1.27 |
/test ci/centos/mini-e2e-helm/k8s-1.25 |
/test ci/centos/mini-e2e-helm/k8s-1.26 |
/test ci/centos/mini-e2e-helm/k8s-1.27 |
/test ci/centos/mini-e2e/k8s-1.25 |
/test ci/centos/mini-e2e/k8s-1.26 |
/test ci/centos/mini-e2e/k8s-1.27 |
/test ci/centos/upgrade-tests-cephfs |
/test ci/centos/upgrade-tests-rbd |
When a volume has AccessType=Block and is encrypted with LUKS, a resize of the filesystem on the (decrypted) block-device is attempted. This should not be done, as the application that requested the Block volume is the only authoritive reader/writer of the data.
In particular VirtualMachines that use RBD volumes as a disk, usually have a partition table on the disk, instead of only a single filesystem. The
resizefs
command will not be able to resize the filesystem on the block-device, as it is a partition table.When
resizefs
fails during NodeStageVolume, the volume is unstaged and an error is returned.Resizing an encrypted block-device requires
cryptsetup resize
so that the LUKS header on the RBD-image is updated with the correct size. But there is no need to callresizefs
in this case.Fixes: #3945
Note: it looks like
e2e/rbd.go
covers this case already, I am not sure why the issue is not hit in the CI.Show available bot commands
These commands are normally not required, but in case of issues, leave any of
the following bot commands in an otherwise empty comment in this PR:
/retest ci/centos/<job-name>
: retest the<job-name>
after unrelatedfailure (please report the failure too!)
/retest all
: run this in case the CentOS CI failed to start/report any testprogress or results